![[アップデート]VPCサブネットを複数のAWSアカウントで共有できるようになりました！！ #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2018/11/eyecatch_reinvent-2018-city_1200x630.jpeg)
[アップデート]VPCサブネットを複数のAWSアカウントで共有できるようになりました！！ #reinvent
コンニチハ、千葉です。
VPCサブネットを複数のアカウント間で共有できるようになりました！！ RAMの共有リソースとしてVPCサブネットが追加された形になります。RAMについて詳しくはこちらのエントリーを確認ください。
[新サービス]でた！AWS Resource Access Manager(RAM)でクロスアカウントのリソース共有が可能に #reinvent
利用用途は？
VPCサブネットを複数のアカウント感で共有できると何が嬉しいか考えてみました。 やはり大きいのは、権限分離かなと思います。AWSアカウントを以下のように用意してみます。
- AWS アカウントA：AVPC用
- AWS アカウントB：システムA
- AWS アカウントB：システムB
この場合は、アカウントAはネットワークチームが管理し、システムAはチームA、システムBはチームBでAWSアカウントを管理します。 こうすることで、権限委譲することができ、アジリティが高まります。また、アカウントが分かれているので、権限管理を中央管理せずに各チームに委譲することができます。
今までだと、1つのAWSアカウントに、VPC管理者、システムA管理者、システムB管理者が共存する必要があり、IAMポリシーとタグを使って権限を細かく管理する必要がありました。これを、AWSアカウント レベルで権限を委譲し、自分のスコープだけ管理できるようになります。
チームAには、チームBのEC2リソースを見せたくないし、操作させたくないということも実現できますね！！
また、部署内で請求を分けたいという要望にも対応できそうです。
AWSアカウントの分け方に関してはこのセッションがめちゃくちゃ参考になったので貼っておきます
[レポート]SEC303 – Architecting Security & Governance across your AWS Landing Zone #reinvent
制限事項
共有されたサブネットに作成できないリソース
- Amazon Aurora Serverless
- AWS Cloud9
- AWS CloudHSM
- AWS Glue
- Amazon EMR
- Network Load Balancer
ひとまず、ALB、EC2、RDSの構成は問題なくとれそうですね！ Amazon EC2インスタンス、Amazon Relational Database Service（RDS）データベース、Amazon Redshiftクラスタ、AWS Lambda関数などは問題なく作成できます。
その他制限事項
- VPC内のサブネットは、同じAWS Organization内にある他のアカウントまたはOUとだけ共有できる
- 所有者は、デフォルトのVPC内にあるサブネットを共有できない
- 参加者は、他の参加者または所有者が所有するセキュリティグループを使用してリソースを起動することができない
- 参加者は所有者に属しているため、VPCのデフォルトのセキュリティグループを使用してリソースを起動することができない
アクセス権限は？
- 所有者のアクセス許可(共有する側)：VPC所有者は、サブネット、ルートテーブル、ネットワークACL、VPCピアリング接続、VPCエンドポイント、プライベートリンクエンドポイント、およびインターネットゲートウェイ、NATゲートウェイ、仮想ゲートウェイ、トランジットゲートウェイアタッチメントを含むゲートウェイを含むすべてのVPCレベルエンティティの作成、管理、削除が可能
- 参加者のアクセス権限(共有される側)：
- Amazon EC2インスタンス、Amazon RDSデータベース、ロードバランサなどのリソースの作成、管理、削除が可能
- ルートテーブルの詳細と、それらと共有されているサブネットに接続されているネットワークACL可能
- ルートテーブル、ネットワークACL、サブネットなど、VPCレベルのエンティティの変更不可
- 他の参加者に属するセキュリティグループを参照したり、またはセキュリティグループIDを使用して所有者を識別します
- 自分が所有するインターフェイスに対してのみフローログの有効化が可能
料金はどうなる？
共有した側
- VPCの所有者は、NATゲートウェイ、バーチャルゲートウェイ、トランジットゲートウェイ、プライベートリンク、およびVPCエンドポイントでの時間別料金（該当する場合）、データ処理およびデータ転送料金を支払う
共有された側
- 参加者は、Amazon EC2インスタンス、Amazon Relational Database Serviceデータベース、Amazon Redshiftクラスター、AWS Lambda関数などのアプリケーションリソースに対して支払う
- 参加者は、アベイラビリティーゾーン間のデータ転送間のデータ転送、VPCピアリング接続によるデータ転送、AWS Direct Connectゲートウェイ経由でのデータ転送に関連するデータ転送料金を支払う
やってみた
VPCを共有し、そこにEC2を立ててみます。イメージとしてこんな感じです。
共有する側の作業
VPCとサブネットを作っておきます。ポイントとしては、アカウントAとアカウントBのAZ-A, AZ-Cが異なる可能性があるため、一意に識別するためのAZ IDというものが追加されています。
作成したサブネットをRAMで、別のアカウントに共有してみます。
共有する側の設定は以上です。
共有される側の作業
共有された側のAWSアカウントの状況を見てみます。RAMの画面からシェアされていることを確認できました。
VPCサブネットをみると共有されていることがわかります。
共有されているルートテーブルは見ることができましたが、上記で記載した使用通り編入ボタン自体が表示されず、参照のみ可能でした。
EC2を立ててみます。
共有されたサブネットに問題なく起動できました！
最後に
RAMの機能で、アカウント間でVPCを共有することができるようになりました。これは、複数チームで対応するときの権限や請求に関する制約事項をうまく適用させるための1つの手段になりそうです。今後もRAMのアップデートに期待です！！
